In the early days of integrated circuit technology, logic circuits, such as shift registers, multiplexers, adders and so on, were constructed from digital IC's. These small scale integration (SSI) IC's usually contained a small number (e.g. four-eight) of logic gates such as AND gates, OR gates, flip-flops, latches and such, requiring a few dozen or so transistors. As the technology advanced, increasing numbers of transistors could be incorporated into an IC. Today, semiconductor manufacturers are able to fit millions of transistors onto a single die, resulting in highly sophisticated chips such as the modern microprocessor.
Equally sophisticated are the systems into which these VLSI (very large scale integration) and ULSI (ultra-large scale integration) chips are incorporated. Such systems usually employ a number of custom logic chips to provide a variety of supporting logic functions. Gate arrays were developed which permitted manufacturers to quickly implement a customer's logic design. These devices consisted of an array of logic gates manufactured using standard methods. Customization of the devices took place during the final steps of manufacture wherein a metallization layer connected the logic gates to implement the desired logic function.
These gate arrays evolved into programmable devices, providing greater flexibility for the designer who may require only a small number of the devices, or who has not fully developed the logic design but may require small samples for testing. Another type of programmable logic device employs fuses to provide interconnections among the logic gates in the devices. The fuses were blown to break a connection, or in the case of so-called anti-fuses connections were formed. Such devices, therefore, could be used only once, storing only one set of logic functions.
Continued evolution of programmable logic devices has resulted in the development of re-programmable interconnects, and more importantly the development of configurable logic cells. As the name implies, a configurable logic cell permits a designer to program the cell to function as any one of a number of basic logic gates or higher level logic functions. Current manufacturing technology makes possible the production of high density devices having many thousands of configurable logic cells and their associated interconnects, known as field programmable gate arrays (FPGA's). The availability of these high density devices enables the designer to employ increasingly complex logic functions. Like their predecessors, FPGA's include programmable interconnects. Moreover, the interconnects are reprogrammable, further increasing the utility of FPGA's.
Reconfiguring these reprogrammable FPGA's, however, has typically required that the entire device be reconfigured. A further evolutionary step of these devices is represented in an FPGA manufactured by Atmel Corp., assignee of the present invention. Known as dynamically reconfigurable FPGA's, these devices allow only selected portions of the logic array to be reconfigured. In this way changes can be made to an FPGA without having to program the entire device, permitting only the selected portions of the array to be reconfigured.
Referring to FIG. 1, a typical FPGA 100 includes a plurality of configurable logic cells 130, configurable I/O blocks 110, and configurable inter- connects 120, 122, collectively referred to as resources of the FPGA. Although the interconnects 120, 122 are shown as a grid of individual interconnect lines, each "line" in actuality is a set of interconnect lines, as shown in FIG. 3B for instance. Each logic cell 130 and I/O block 110 includes data lines 140, 142 which can be selectively coupled to the interconnects 120, 122.
A typical design cycle begins with the design of one or more logic circuits which will then be implemented in an FPGA. A logic design includes logic gates and interconnections among the logic gates. Certain designs, however, such as digital filters incorporate the use of "constants," namely strings of ones and zeroes, to define their behavior. For the purposes of the description of the present invention, such constants are regarded as being part of the design and also will be referred to as logic gates.
For example, FIG. 2 shows a simple logic design. Each element in the logic design is identified by an instance name. Thus, the AND gates and the OR gate in FIG. 2 are named, G1-G3. FIG. 3A shows how the logic design might appear in the FPGA 100'. Each of the gates G1-G3 and the interconnections shown in FIG. 2 is mapped to selected logic cells and interconnects as shown in FIG. 3A. Similarly, the inputs A-D and the output OUT (FIG. 2) are mapped to selected I/O blocks. Thus, interconnects 120a-120c and 122a-122c (shown high-lighted) connect together logic cells G1-G3 and I/O blocks 110a-110e. A magnified portion of the configuration of FIG. 3A is shown in FIG. 3B, illustrating the specific interconnections among the various logic cells, interconnects, and I/O blocks. Although the design in the figures do not show the use of constants, it is known that logic cells in a modern FPGA can be configured to output a logic "1" or a logic "0" and that groups of logic cells can be so configured to produce one or more strings of ones and zeroes as needed.
The steps for transferring the design of FIG. 2 to an FPGA, such as the one shown in FIG. 3A, will now be explained. Since most of today's designs tend to be quite complex in functionality, a computer-aided design (CAD) tool usually is employed to facilitate the design process. Thus in FIG. 4, the design flow 200 begins with entering the initial design for a logic circuit, step 210, as for example through the use of a CAD tool.
Next, is the placement and routing of the logic gates of the logic circuit, step 212. As a result of the placement and routing step, a design database is generated, step 214. The design database specifies those logic cells, I/O blocks, and interconnects (i.e. resources) of the FPGA which will participate in the implementation of the logic circuit, including locations of selected resources and their routing or logic configurations. FIG. 1 illustrates one of a number of coordinate systems used to identify the location of logic cells. In the convention shown in FIG. 1, the cells are numbered in left to right order and from bottom to top, beginning with the lower leftmost cell (0,0) and ending with the upper rightmost cell (3,3). Typically, the design database additionally includes the instance names which were assigned to the elements of the logic circuit during the design phase, FIG. 2.
From the information contained in the design database, a configuration bitstream is generated by a tool commonly referred to as a bitstream compiler, step 216. The bitstream compiler takes the location and configuration information stored in the design database and creates the defining bitstrings which will configure the various resources within the FPGA. At the physical level, the defining bitstrings represent the ON/OFF state of the transistors (switches) within the FPGA which actually control the configuration of each logic cell and I/O block, and the interconnections among the logic cells and the I/O blocks.
At this point, the configuration bitstream either may be downloaded to the logic array thereby configuring the device, step 218a, or the bitstream may be saved onto disk, step 218b. These alternatives are indicated in FIG. 4 by dashed lines.
As occasionally happens, it may be desirous to make changes to the initial design, even though the design has been debugged and operates as intended. For example, new requirements may result in changes to the functional specification which might necessitate changes to the initial design. Using conventional prior art techniques, a modification to a final version of the initial design, step 220, leads to a repeat of the previous steps. Thus, the designer accesses the final version of the initial design using a CAD tool and makes the desired changes to the design. A second placement and routing step is performed, step 222, from which a second design database is generated, step 224. A second configuration bitstream is then created by the bitstream compiler based on the new design database, step 226.
As with the first configuration bitstream, the second configuration bitstream may or may not be downloaded to the FPGA. If a download is desired, two choices are available: The bitstream can be downloaded to the FPGA in its entirety, thereby reconfiguring the entire array to contain the modified design. Alternatively where the FPGA is dynamically reconfigurable, meaning that the device is capable of being partially reconfigured, only those portions of the second configuration bitstream which correspond to the changes in the design can be downloaded. This is accomplished first by determining the differences between the first and second configuration bitstreams, step 228, to produce a partial (reconfiguration) bitstream. The partial bitstream then is downloaded to the dynamically reconfigurable FPGA, step 230, thereby effectuating a partial reconfiguration of the FPGA in which only those logic cells, interconnects, and I/O's involved in the modified design are reprogrammed. Finally, the cycle can be repeated for additional modifications to the design, step 232, as changes in the functional requirement of the design occur.
Placement and routing of the logic gates in a design is a computationally intensive activity. As designers tend toward increasingly complex designs due to the availability of high density FPGA's, the placement and routing operation could significantly increase. Under the prior art approach outlined in FIG. 4, the amount of time dedicated to placement and routing computations can reach alarming levels considering that each iteration of the design cycle may require a full placement and routing operation.
Another aspect of the prior art approach is the possibility that a modified design will result in a placement and routing configuration that is different from the previous design. This becomes a concern if the previous design had been fine tuned to provide certain critical timing behavior. A subsequent design that is processed through a full placement and routing operation might result in a different placement of logic gates with different net lengths, thus adversely affecting the timing of the circuit. This is an unacceptable circumstance where real-time applications are involved.
What is needed is a methodology which improves upon the prior art with respect to the turn-around time for the redesign of fully completed and debugged logic designs. It is also desirable to have a development methodology whereby portions of a prior design which are not involved in a design modification remain unaffected.
Up to this point, the discussion has centered around the design of logic circuits in the environment of the designer's engineering lab. It is observed, however, field applications of FPGA's may not be suitable to a single static design. Although FPGA's can be reconfigured in the field under actual operating conditions, the new configurations typically consist of complete designs stored in non-volatile devices such as EPROM. Configuration bitstreams are read from the EPROM and downloaded into the FPGA. Thus, the suite of available configurations is limited to the storage capacity of the EPROM. In applications such as adaptive filtering, it is highly desirable that the filter response be alterable at run time based on criteria such as the frequency and phase characteristics of the data being filtered, i.e. conditions that usually are unpredictable. In such cases, it is not possible to specify new configurations, such as filter parameters, a priori.
What is also needed then is the ability to configure an FPGA on-the-fly, in response to the environment in which the device is operating. In addition, since only portions of the FPGA need to be reconfigured, as in the case of an adaptive filter, it is desirable to have on-the-fly partial reconfiguration capability.